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Abstract. We present CurryBrowser, a generic analysis environment 
for the declarative multi-paradigm language Curry. CurryBrowser sup- 
ports browsing through the program code of an application written in 
Curry, i.e., the main module and all directly or indirectly imported mod- 
ules. Each module can be shown in different formats (e.g., source code, 
interface, intermediate code) and, inside each module, various properties 
of functions defined in this module can be analyzed. In order to sup- 
port the integration of various program analyses, CurryBrowser has a 
generic interface to connect local and global analyses implemented in 
Curry. CurryBrowser is completely implemented in Curry using libraries 
for GUI programming and meta-programming. 



1 Overview 

CurryBrowser is intended as a tool to support the analysis of declarative pro- 
grams. It can be used to browse through an implementation written in the declar- 
ative multi-paradigm language Curry [11117) , analyze properties of individual or 
all functions defined in a module, or visualize dependencies between modules or 
functions. It can be also used as a testbed for program analyses (the analyses 
of functional logic programs is still ongoing research) since it supports the easy 
integration of new program analyses by a generic interface. The implementation 
of CurryBrowser is based on an intermediate language to which functional, logic, 
and also integrated functional logic programs can be compiled (e.g., see |3I5I19| ). 
Thus, it is also adaptable to other declarative languages. 

To get an impression of the use of CurryBrowser, Figure Q] shows a snapshot of 
its use on a particular application (here: the implementation of CurryBrowser). 
The upper list box in the left column shows the modules and their imports in 
order to browse through the modules of an application. Similarly to directory 
browsers, the list of imported modules of a module can be opened or closed by 
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— Read an existingf ! ) FlatCurry file w.r.t. current load path: 
readFlatCurryFilelrtLoadPath prt mod - do 

rub f i lename <- f indFilelriLoadPath mod [".fey"] 
maybe (error $ "FlatCurry file " ++mod++" . f cy not found!") 
(readFlatCurryFileAndReport prt mod) 
ffibfi lename 



readFlatCurryFileAndReport prt mod filename - do 
size <- fileSise filename 

prt $ "Reading FlatCurry file of module '"++mod+- 
prog <- readFlafeCTirryFile filename 
seq (prog==prog) (return prog) 



("++show size++" bytes) . 



Finds the first file with a possible suffix in the load path: 

findFilelnLoadPath : : String -> [String] -> 10 (Maybe String) 
f indFilelriLoadPath file suffixes = do 

loadpath <- getLocalLoadPath 

f indFilelnPath file suffixes loadpath 



— computes real load path in case of non-local first program argument 
■jrrL :■ : ■ LLv>d£>r . . - 
Select functions... ■ focus in code loadpath <- getloadPath 
arge <- getArge 
if null args 
then return loadpath 

else return (dirHame (head args) : tail loadpath) 
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Fig. 1. The main window of CurryBrowser 



clicking. After selecting a module in the list of modules, its source code, inter- 
face, or various other formats of the module can be shown in the main (right) 
text area. For instance, one can show pretty-printed versions of the interme- 
diate flat programs (see below) in order to see how local function definitions 
are translated by lambda lifting [5D] or pattern matching is translated into case 
expressions [11124] , Since Curry is a language with parametric polymorphism 
and type inference, programmers often omit the type signatures when defining 
functions. Therefore, one can also view (and store) the selected module as source 
code where missing type signatures are added. 

Below the list box for selecting modules, there is a menu ("Analyze selected 
module" ) to analyze all functions of the currently selected module at once. This 
is useful to spot some functions of a module that could be problematic in some 
application contexts, like functions that are impure (i.e., the result depends 
on the evaluation time) or partially defined (i.e., not evaluable on all ground 
terms). If such an analysis is selected, the names of all functions are shown in 
the lower list box of the left column (the "function list" ) with prefixes indicating 
the properties of the individual functions. 



The function list box can be also filled with functions via the menu "Select 
functions" . For instance, all functions or only the exported functions defined in 
the currently selected module can be shown there, or all functions from different 
modules that are directly or indirectly called from a currently selected function. 
This list box is central to focus on a function in the source code of some module 
or to analyze some function, i.e., showing their properties. In order to focus on 
a function, it is sufficient to check the "focus on code" button. To analyze an 
individually selected function, one can select an analysis from the list of available 
program analyses (through the menu "Select analysis", see also Figure[3]). In this 
case, the analysis results are either shown in the text box below the main text 
area or visualized by separate tools, e.g., by a graph drawing tool for visualizing 
call graphs. Some analyses are local, i.e., they need only to consider the local 
definition of this function (e.g., "Calls directly," "Overlapping rules," "Pattern 
completeness", see Section @|, where other analyses are global, i.e., they consider 
the definitions of all functions directly or indirectly called by this function (e.g., 
"Depends on," "Solution complete," "Set-valued"). Finally, there are a few ad- 
ditional tools integrated into CurryBrowser, for instance, to visualize the import 
relation between all modules as a dependency graph. These tools are available 
through the "Tools" menu. 

In the next section, we review some features of Curry in order to show some 
details of the implementation of CurryBrowser in Section [3] The currently avail- 
able analyses and tools are sketched in Section |4] before we conclude in Section [5l 

2 Curry Programs 

Since CurryBrowser is implemented in Curry and intended to be applied to 
Curry programs, we review in this section some aspects of Curry programs that 
are necessary to understand the functionality and implementation of our pro- 
gramming environment. More details about Curry's computation model and a 
complete description of all language features can be found in [11117) . 

Curry is a declarative multi-paradigm language combining in a seamless 
way features from functional, logic, and concurrent programming and supports 
programming-in-the-large with specific features (types, modules, encapsulated 
search). From a syntactic point of view, a Curry program is a functional pro- 
gram extended by the possible inclusion of free (logic) variables in conditions and 
right-hand sides of defining rules. Curry has a Haskell-like syntax [22], i.e., (type) 
variables and function names usually start with lowercase letters and the names 
of type and data constructors start with an uppercase letter. The application of 
a function / to an argument e is denoted by juxtaposition ("/ e"). 

A Curry program consists of the definition of functions and the data types 
on which the functions operate. Functions are defined by conditional equations 
with constraints in the conditions. They are evaluated lazily and can be called 
with partially instantiated arguments. 



Example 1. The following program defines the types of Boolean values and poly- 
morphic lists and functions to concatenate lists and to compute the last element 
of a list: 

data Bool = True I False 
data List a = [] la: List a 

cone : : [a] -> [a] -> [a] 

cone [] ys = ys 

cone (x:xs) ys = x : cone xs ys 

last xs I cone ys [x] =:= xs = x where x,ys free 

The data type declarations define True and False as the Boolean constants and 
[] (empty list) and : (non-empty list) as the constructors for polymorphic lists (a 
is a type variable ranging over all types and the type "List a" is usually written 
as [a] for conformity with Haskell). The (optional) type declaration ("::") of 
the function cone specifies that cone takes two lists as input and produces an 
output list, where all list elements are of the same (unspecified) typeQ 

The operational semantics of Curry [1111] is a conservative extension of lazy 
functional programming (if free variables do not occur in the program or the 
initial goal) and (concurrent) logic programming. To describe this semantics, 
compile programs, or implement analyzers and similar tools, an intermediate 
representation of Curry programs has been shown to be useful. Programs of this 
intermediate language, also called flat programs, contain a single rule for each 
function where the pattern matching strategy is represented by case/or expres- 
sions. The basic structure of flat programs is defined as follows H 
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A program P consists of a sequence of function definitions D with pairwise differ- 
ent variables in the left-hand sides. The right-hand sides are expressions e com- 
posed by variables, constructor and function calls, case expressions, and disjunc- 
tions. A case expression has the form (f)case e of {c\ ~x~^l — > e±, . . . , Ck ~x~^ — > 
ek}, where e is an expression, Ci, . . . , Ck are different constructors of the type of 
e, and e\,...,ek are expressions. The pattern variables x ni are local variables 
which occur only in the corresponding subexpression a . The difference between 
case and fcase shows up when the argument e is a free variable: case suspends 
(which corresponds to residuation) whereas fcase nondeterministically binds this 
variable to the pattern in a branch of the case expression (which corresponds to 
narrowing) . 



1 Curry uses curried function types where a->/3 denotes the type of all functions 
mapping elements of type a into elements of type (3. 

2 at denotes a sequence of objects oi , . . . , o&. 



The PAKCS implementation of Curry [T3] provides a library for meta- 
programming which contains the data types for representing flat programs (i.e., 
the data types and functions defined in a module) and an I/O action for read- 
ing a module and translating its contents into the corresponding data term. For 
instance, a module of a Curry program is represented as an expression of type 

data Prog = Prog String [String] [TypeDecl] [FuncDecl] [OpDecl] 

where the arguments of the data constructor Prog are the module name, the 
names of all imported modules, the list of all type, function, and infix operator 
declarations. Furthermore, a function declaration is represented as 

data FuncDecl = Func QName Int Visibility TypeExpr Rule 

where the arguments are the qualified name (i.e., a pair of module and func- 
tion name), arity, visibility (Public or Private), type, and rule (of the form 
"Rule arguments expr") of the function. The remaining data type declarations 
for representing Curry programs are similar but we omit them for brevity. 

3 Implementation 

CurryBrowser is implemented in Curry using libraries for GUI programming 
|13j and meta-programming sketched above. In order to ensure a fast startup 
time, only the interface files of all modules (they have the same structure as 
flat programs but contain only the type signatures of exported functions and 
data types) are read at the beginning. This information is sufficient to show 
the import structure of all modules in the initial main window. Complete flat 
programs are only read as demanded by the analyses. 

As discussed in Section!]] CurryBrowser offers a generic interface to integrate 
various analysis tools for declarative programs. Since flat programs are an ap- 
propriate abstraction level for implementing such tools 8 15 16 , this interface 
is based on them. To be more concrete, CurryBrowser provides the following 
type definition to connect program analyzers (where a is the type of the analysis 
result): 

data FunctionAnalysis a = 

LocalAnalysis (FuncDecl -> a) 

I LocalDataAnalysis ( [TypeDecl] -> FuncDecl -> a) 
I GlobalAnalysis ([FuncDecl] -> [(QName, a)]) 

I GlobalDataAnalysis ([TypeDecl] -> [FuncDecl] -> [(QName, a)]) 

A local analysis associates results to single function definitions (e.g., "Calls di- 
rectly"), a local data analysis requires in addition the type declarations (e.g., 
"Pattern completeness"), and global analyses require all defined functions and 
yield lists containing for each function name (QName) an associated result. Thanks 
to laziness, the results for all functions are not computed at once but only as 
demanded by the user. 

As a simple example, consider the "Overlapping rules" analysis. This analysis 
is intended to indicate whether a function is defined by rules with overlapping 



left-hand sides. Although this analysis is simple, it is interesting since functions 
(sometimes accidentally) defined by overlapping rules might cause nondetermin- 
istic evaluations even for ground expressions. This property can be easily spotted 
in the flat representation of Curry programs as an occurrence of a disjunction 
(or) in the right-hand side of the rule defining this function. Thus, the analysis 
is a local one that can be implemented as follows: 

isOverlappingFunction : : FuncDecl -> Bool 

isOverlappingFunction (Func _ (Rule e)) = orlnExpr e 

where the operation orlnExpr checks for occurrences of disjunctions in an ex- 
pression. 

For the simple addition of new analyzers, the implementation of Curry- 
Browser has a configuration module containing definitions of the currently avail- 
able tools. For instance, it contains a constant f unctionAnalyses of type 

f unctionAnalyses : : [(String, FunctionAnalysis AnalysisResult)] 

where each element in this list consists of the name and the operation imple- 
menting the analysis. The result type of a concrete function analysis indicates 
the way the result is handled inside CurryBrowser. Currently, this type is defined 
as 

data AnalysisResult = MsgResult String 
I ActionResult (10 ()) 

Thus, the analysis result is a string to be shown inside the CurryBrowser in- 
terface or an I/O action to visualize the result via an external tool (e.g., a 
graph drawing tool). Thus, to test a new analysis by integrating it into Cur- 
ryBrowser, one has to connect its implementation by adding a new element to 
the list f unctionAnalyses and recompile the system. Then, the CurryBrowser 
environment provides the analysis with the appropriate data whenever the user 
selects the analysis. 

Note that the possible result types of analyses to be integrated into Curry- 
Browser are fixeco since the implementation needs to know what to do with the 
analysis result. Therefore, the current implementation supports 

— string results that are shown inside the main window, or 

— I/O actions that calls some external tool for visualization. 

For instance, to show the dependency graph of a function, the corresponding 
global analysis computes a graph structure and calls an external program, the 
DOT graph drawing tooQ, to visualize this graph structure (see Figure [2] for an 
example). Since the main GUI of CurryBrowser is executed in the I/O monad, 
the event handlers that implement reactions to user events are I/O actions [T3] . 
Thus, analyses with a result type 10 can be executed by the event handlers 

3 The possible analysis results might be extended in future version of CurryBrowser. 
For instance, one could map complex analysis results into a source code transforma- 
tion that is shown in the code widget. 

4 http : / /www . graphviz . org/ 




Fig. 2. Visualization of the dependency graph of the prelude function elem 



responsible for analyzing programs. In order to avoid the crash of the Curry- 
Browser environment if some analyses fails with run-time errors, the execution 
of an analyses is wrapped into an exception handler. 

The restriction to a fixed set of analysis result types requires the transforma- 
tion of arbitrary program analyses when they are integrated into CurryBrowser. 
For instance, the "Overlapping rules" analysis sketched above delivers Boolean 
results that must be converted into appropriate strings shown to the user. For 
this purpose, one can define a simple conversion operation to show the result of 
the overlapping analysis: 

showOverlap : : Bool -> String 
showOverlap True = "Overlapping" 
showOverlap False = "Not Overlapping" 

In order to support a simple conversion of arbitrary analyses into the analyses 
with string results as required by the interface of CurryBrowser, the implemen- 
tation of CurryBrowser contains the following conversion operation: 

showWithMsg : : FunctionAnalysis a 
-> (a->String) 

-> FunctionAnalysis AnalysisResult 



showWithMsg (LocalAnalysis ana) showresult = 

LocalAnalysis (\f -> MsgResult (showresult (ana f))) 

showWithMsg (LocalDataAnalysis ana) showresult = 

LocalDataAnalysis (\tds f -> MsgResult (showresult (ana tds f))) 

showWithMsg (GlobalAnalysis ana) . . . 

showWithMsg (GlobalDataAnalysis ana) . . . 

Based on this conversion operation (which is also defined as an infix operator), it 
is easy to integrate an analysis like isOverlappingFunction into CurryBrowser 
by adding an element to the configuration list f unctionAnalyses as follows: 

f unctionAnalyses = 
[..., 

("Overlapping rules", 
LocalAnalysis isOverlappingFunction 

'showWithMsg' showOverlap) , 

. . .] 

Similarly to the list constant f unctionAnalyses, the configuration module of 
CurryBrowser contains two further list constants that specify the available anal- 
yses: 

— a list constant allFunctionAnalyses that contains analyses that are applied 
to all functions of the selected module (e.g., applying the analysis "Pattern 
completeness" to all functions of a module is useful to spot those functions 
with incomplete pattern definitions): the results of these analyses are shown 
as prefixes in the column showing the list of all functions of the currently 
selected module; 

— a list constant moduleAnalyses that contains analyses that are applied to 
complete modules (e.g., to generate the interface, the flat representation of 
a module, or a source code representation where missing type signatures are 
added); similarly to a function analysis, the result of a module analysis is 
either a (program) text to be shown in the main window or an I/O action 
that visualizes the result by an external tool. 

Thus, it is fairly easy to integrate existing tools (implemented in Curry) into 
CurryBrowser. 

4 Available Analyses and Tools 

This section shortly surveys the analyses and tools that are currently available 
in CurryBrowser (see Figure[3]). Due to the simple integration of further analyses 
and tools, this set is likely to be extended in future releases of CurryBrowser. 

In the flat representation of Curry (see Section pattern matching is made 
explicit by case expressions and disjunctions, and local definitions are "global- 
ized" by lambda lifting [2U] . Although it is possible to deal with local definitions 
at run time (e.g., 6 ), lambda lifting is useful to simplify the operational model 
[1] of Curry programs and, thus, often used in implementations of functional logic 
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-- Read an existing(l) FlatCurry file w. : 
readrlatCurryFilelnLoadPath prt mod = do 

jTlli t: i lename <- f indFilelnLoadPath mod [".fey"] 
maybe (error $ "FlatCurry file "++mod++" . f cy not found 
(readFlatCurryFileftndReport prt mod) 
mbf ilename 
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readFlatCurryFileAndReport prt mod filename 
size <- fileSize filename 
prt $ "Reading FlatCurry file of module '" 
prog <- readFlatCurtyFile filename 
seq (prog==prog) (return prog) 
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f indFilelriLoadPath file suffixes : 
loadpath <- getLocalLoadPath 
f indFilelnPath file suffixes loadpath 

-- computes real load path in case of non-local first 
getLocalLoadPath = do 

loadpath <- getLoadPath 

args <- getfirgs 

if null args 
then return loadpath 

else return (dirName (head args) : tail loadpath) 
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Fig. 3. Selection of a function analysis 



languages (e.g., |3|5|21j . Thus, it is sometimes interesting to show the effect of 
these transformations performed by the front end of a Curry implementation. 
For this purpose, CurryBrowser can show the flat representation of each function 
or module as well as a source-like representation where case expressions and dis- 
junctions are translated back into pattern-based definitions but local definitions 
are kept globalized to get an impression of the program usually passed to a back 
end. Furthermore, the following analyses are available for individual functions: 



Calls directly (local analysis): Shows all functions that are directly called by 
this function. 

Depends on (global analysis): Shows all functions that might be directly or in- 
directly called in the rules defining this function. 

Dependency graph (global analysis): Shows the dependency graph of the se- 
lected function. This is a combination as well as a graphical visualization of 
Calls directly and Depends on, i.e., an arc is drawn from each function 
symbol to all functions directly called in the rules defining this function and 



all reachable function nodes are included in the graph (see Figure for an 
example) . 

Local dependency graph (global analysis): Shows the dependency graph of 
the selected function restricted to all rules occurring in the current mod- 
ule. This is useful for complex functions, e.g., depending on other non-trivial 
library functions, where the complete dependency graph becomes unreadable 
due to its size. 

Called by (global analysis): Shows the list of all functions in the current mod- 
ule that call this function in their defining rules. 

Overlapping rules (local analysis): Shows whether the function is defined by 
overlapping rules (which might cause nondeterministic evaluations even for 
ground expressions). This is interesting for logic programming but might be 
also useful for purely functional programs. 

Right-linear rules (local analysis): Shows whether the function is defined by 
right- linear rules, i.e., rules where each variable has at most one occurrence 
in the right-hand side. 

Right-linearity (global analysis): Shows whether the function is defined by 
right-linear rules and depends only on functions defined by right-linear rules. 
This information is useful for some program optimizations (e.g., [1]). 

Pattern completeness (local data analysis): Shows whether the pattern 
matching is exhaustive, i.e., if the function is reducible on any combination 
of (well-typed) ground constructor argument terms. 

Totally defined (global data analysis): Shows whether the function is totally 
defined, i.e., if the function evaluates to a value for any combination of (well- 
typed) ground constructor argument terms. This is the case if it directly or 
indirectly depends only on operations that are pattern complete. 

Solution completeness (global analysis): Shows whether the function is op- 
erationally complete, i.e., if it is ensured that the execution of the function 
does not suspend for any arguments. 

Nondeterministic (global analysis): Shows whether the function is possibly 
nondeterministic, i.e., if it directly or indirectly depends on an operation 
defined by overlapping rules so that it might deliver (nondeterministically) 
two values for the same ground constructor arguments. 

Set-valued (global analysis): Shows whether the function is possibly set- 
valued, i.e., if it directly or indirectly depends on an operation defined by 
overlapping rules or rules containing extra variables (variables occurring in 
the right-hand side but not in the left-hand side) so that an application to 
some ground constructor arguments is equal to a set of more than one value. 
For instance, the prelude function unknown defined by 

unknown = x where x free 

is set-valued but not nondeterministic: the evaluation of unknown is deter- 
ministic (and yields a fresh logic variable) but, from a semantical point of 
view, it is set-valued since it denotes any possible value. 
Purity (global analysis): Shows whether the function is pure (referentially 
transparent), i.e., if it is ensured that it delivers always the same values 




for the same ground constructor arguments at each time and all schedulings 
of the evaluation. This might not be the case if committed choice or sending 
via ports is executed during its evaluation [12j . 

Finally, there are also useful tools to process complete modules or collections 
of modules. For instance, beyond showing the source code, interface, and flat 
representation of a module, one can also show a version of the source code where 
type signatures are added to functions where the programmer has omitted them. 

To get more information about the import structure between modules, one 
can show all modules directly imported by the current one together with their 
exported functions that are accessed in the current module. This is useful to 
spot superfluously imported modules. Finally, one can also visualize the entire 
import relation between all modules of the currently loaded application as a 
module dependency graph (see Figure H] for an example) . 



5 Conclusions 



We have presented CurryBrowser, a generic analysis environment for Curry pro- 
grams. CurryBrowser supports browsing through the modules of an application 
and offers a wide range of analysis tools in an integrated manner. The currently 
available set of analyses and tools can be easily extended due to the generic 
interface offered by the implementation of CurryBrowser. 

The mostly related system (and, in some sense, its predecessor) is CIDER 
|15j . an environment to analyze single Curry modules. In contrast to CIDER, 
CurryBrowser can be applied to complete applications consisting of several mod- 
ules and supports the browsing through the module structure. Furthermore, Cur- 
ryBrowser provides a better structure to integrate analyzers: CIDER assumes 
that every analysis takes the complete program as input, whereas CurryBrowser 
distinguishes between different kinds of analyses (local, global, data-dependent) 
and provides them with the appropriate information from the modules and func- 
tions selected by the user. 

Another related system is IT>£ [10] . a graphical development environment 
for the functional logic languages Toy and Curry. XT>£ supports the writing of 
programs in a standard text editor window and the compilation and execution of 
programs. However, IT>£ does not offer further tools, e.g., for program analysis. 
This is in contrast to the Ciao Preprocessor (CiaoPP) [18] . a tool integrat- 
ing sophisticated program analyses with validation and transformation methods 
for logic programs. The emphasis of CiaoPP is the use of program analyses to 
manipulate logic programs rather than a graphical programming environment 
supporting an easy way to browse through programs, as in CurryBrowser. 

CurryBrowser is completely implemented in Curry. The advanced program- 
ming techniques offered by Curry (e.g., higher-order functions, demand-driven 
evaluation, meta-programming, high-level abstractions with logic variables for 
GUI programming [13 ) has supported the fast and maintainable implementation 
of this environment. The size of the complete implementation of CurryBrowser 
is approximately 1400 lines of Curry code. This includes the implementation of 
the graphical user interface and all currently available analyses and tools. In ad- 
dition, the total size of all imported system libraries is approximately 2500 lines 
of Curry code. These numbers provide an indication of the advantages obtained 
by the use of declarative high-level programming languages for the implementa- 
tion of complex systems. The implementation of CurryBrowser is freely available 
with the latest distribution of PAKCS [14] where it has been integrated for easy 
use. 

For future work, it is interesting to integrate further tools into CurryBrowser, 
like tools for program transformation (e.g., partial evaluation [2J, refactoring 
[23 ), program observation [7], tracing [9], in order to obtain a comprehensive 
programming environment. 
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